有一次我調整區塊 4「功能範圍」的配分，從 20 分提高到 25 分。我很快改完了，改的是《問題題庫》裡那行「滿分 20 分」。
測試時發現不對勁：進度條顯示「區塊 4：20/25」，可是 SA 就緒度總分卻還是用舊的權重在算，整份分數對不齊。
後來發現 配分這件事，我同時寫在兩個檔案裡：《問題題庫》寫面向配分，《SA就緒度評分》寫加權配分表。我只改了前者，後者忘了。
那次之後我才真正意識到：14 份 Knowledge 不是 14 個獨立檔案，是一張網。改一個節點，會扯動好幾條線，漏掉任何一條，工具就出錯。
Day 6 講拆檔的好處（檢索準、好維護、職責清楚），Day 7 講 Instructions 怎麼省字。但拆檔有代價，這個代價就是耦合：本來在一份大檔裡，改哪都看得到；拆開之後，某個規則散落在三四個檔，改一個忘了另一個。
靠記憶絕對會出事，所以我做了一份內部維護文件：《設計關聯與變更檢查》。它不上傳給 GPT，純粹是給我自己（跟協作的AI）看的「連動地圖」。
這份文件分成五個部分：
核心精神是一句話：不要靠記憶，要靠清單。
10 個連動點裡，有 3 個改下去會飄很遠
鼠勾以把功能分成 10 類（表單、選擇、查詢、交易、預約、上傳、通知、權限、個資、匯出）。這個分類同時出現在兩個檔：《規格基線檢查表》和《例外情境檢查表》。
只要新增或改一個類型，兩個檔都得改，而且類型定義要字字對齊。改一個忘一個，GPT 就會在區塊 4 用新分類、區塊 7 用舊分類，行為自相矛盾。
區塊 4 結尾會問 5 題系統決策（主系統、後台、資料、外部對接、排程的「沿用 vs 新建」）。這 5 題牽動的檔案多到誇張：
規格基線檢查表（問題本體）
→ 問題題庫（區塊 4 結尾追問）
→ 流程與規則（區塊 4 特別段）
→ PRD 模板（系統架構決策表）
→ 產出前自檢（類別 F）
→ 挑戰檢查規則（未指明系統的 3 條）
→ 工時估算（新建項目的 buffer）
七個檔。改 5 題的任何一題，這七處都要同步。這是全專案連動最廣的一個點。
就是開場那個事故。配分同時寫在《問題題庫》（面向配分）和《SA就緒度評分》（加權配分表），兩處數字必須相等。而且快速模式、標準模式、完整模式各有一套配分，三套都要對。
知道哪裡會噴之後，我把常見的改動整理成 5 個「劇本」。遇到對應情境，照劇本逐步走，不靠記憶：
| 劇本 | 觸發情境 | 大致要動的檔 |
|---|---|---|
| A | 新增/修改一個功能類型 | 規格基線 + 例外情境 + 問題題庫 |
| B | 新增一個問答區塊 | 問題題庫 + SA評分 + 流程規則 + Instructions + PRD模板 + 自檢 |
| C | 調整計分配分 | 問題題庫 + SA評分（三種模式都查）+ 工時信心度 |
| D | 改流程圖/畫面清單規範 | 格式範例 + 問題題庫 + 參與者協作圖 + PRD模板 + 自檢 |
| E | 新增一個 Knowledge 檔 | Instructions 清單 + 流程規則 + README + 設計關聯文件本身 |
開場那個事故，就是「劇本 C」沒照走的結果。如果當時我有這張表，就會看到「調配分要同步 SA評分」這一條，不會漏。
劇本是「改之前看」，清單是「改之後勾」。Part 5 是一份可勾選的清單，挑幾條最關鍵的：
每次改完，逐條打勾。聽起來很笨，但笨方法是我想到能在三個月後還記得「當初為什麼這樣改」的方法。如果有更好的方法求分享進步
這份《設計關聯與變更檢查》本身也是維護成本。每次新增一個 Knowledge 檔、發現一個新連動點，都要回來更新它。它不是寫完就放著的文件。
但跟「漏改造成分數錯、行為自相矛盾、使用者以為遇到 bug」的代價比起來，花時間維護一張地圖相對單純。一個高度耦合的系統，有沒有連動地圖，是它能不能被持續迭代的關鍵。
到 Day 8 為止，架構篇講完了：三件套（Day 5）、多份 Knowledge 的分工（Day 6）、Instructions 怎麼省（Day 7）、檔案怎麼連動（今天）。這四篇合起來，是鼠勾以的「骨架」。
從 Day 9 開始進入「機制篇」，這套工具到底怎麼跟需求方PM 對話。第一個主題是最反直覺的一條設計：為什麼一次只能問一題。明明可以一次丟十題加快速度，為什麼我堅持一題一題問？這跟認知負荷有關。
這是 iThome 鐵人賽系列文章。明天見。
iThome鐵人賽
看影片追技術